Subject: Parallel TGs and CP-CP sessions re-establishment

From: Matthew Finlayson <[email-masked]>
Date: Wed, 10 Jul 96 16:55:00 BST

We and some of our OEMs have come across a problem a number of times   
during live testing which reveals a problem with the current   
architecture.  The problem is particularly likely on LANs.  It can lead   
to CP-CP sessions failing to be re-established when a TG fails between   
two nodes with parallel TGs.

Consider the scenerio where two network nodes have two TGs (TG1 and TG2)   
active between them, with CP-CP sessions active on TG1.

       /---------- TG1 ----------\
    NN1                           NN2
       \-----------TG2 ----------/

If TG1 fails, then one of the network nodes (NN1, say) may well detect   
this significantly before the other, perhaps because NN1 had a frame to   
send, and detected the failure at that point, whereas NN2 only detected   
it because of an inactivity timer expiry.  In this window NN1 will try to   
re-establish CP-CP sessions with NN2 over TG2.  The CP LU in NN2 will   
reject this due to Session Limit Exceeded (sense code 0805).

Architecturally, NN1 will then give up (this is not a retryable sense   
code) and report an ADJACENT_CP_ERROR which will remove CP-CP session   
support from TG2 (with a non-activation XID flow).  Even if it retries,   
it is entirely possible that it will reach its retry limit before NN2   
notices that TG1 has gone down (since link inactivity timers are commonly   
fairly long).

When NN2 finally notices that TG1 has gone down, it will be unable to   
re-establish CP-CP sessions, since NN1 will already have removed such   
support from TG2.

There is also the added problem that during the life of NN2's   
link-inactivity timer the CP-CP sessions between NN1 and NN2 appear to be   
active and directed LOCATEs routed across them will fail (causing   
increased broadcast LOCATE traffic in the network and causing some   
session activation flows to fail).

The issue here is not the fact that NN1 notices the link failure before   
NN2, since this can be unavoidable, but the effect that this has on the   
network, and the fact that CP-CP sessions do not eventually get   
re-established successfully.

We can see ways of detecting this condition, although none of them fit   
particularly well with the current architectural model and have dangerous   
side-effects.  Does anyone else have any suggestions?

Matthew.

==============================================================
Matthew Finlayson                  Data Connection Limited
([email-masked])                 Telephone: +44 181 366 1177
                                   Fax:       +44 181 367 8501
==============================================================